7. The Machine Key
As you learned earlier in
this chapter, some organizations use groups of web servers that work
together to host web applications. This arrangement, called a web farm, has some side effects.
For example, if you decide to use session state in a web farm, you must use StateServer or SQLServer mode.
Otherwise, a user's session information might get trapped on one
server. If a subsequent request is directed to another server, the
information will be lost, and a new session will be created. Another
wrinkle occurs with view state and forms authentication .
The problem in both cases is the same—ASP.NET encodes some information
to prevent tampering and verifies the information later. For example,
with view state, ASP.NET adds a hash code, which double-checks the next
time the page is posted back to make sure the user hasn't changed the
hidden view state field (in which case the request is rejected). The
problem that can happen with web farms is that the hash code one web
server creates might not match the hash code expected by another web
server that uses a different secret key. As a result, if a page is
posted back to a web farm and a different web server gets involved, an
error can occur.
To resolve this problem, you
must configure each web server in the web farm to use the same key.
With a web hosting provider, this detail should already be configured.
If you have your own web farm, it won't be—the default is for each
server to create its own random key. So, obviously, these keys won't
match.
To configure web servers to
use the same key, select the website, and double-click the Machine Key
icon (in the ASP.NET section). Then, clear all the four check boxes
(which tell IIS to automatically generate application-specific keys).
Finally, enter the validation key and decryption key in the two
provided text boxes (Figure 13), and then click the Apply link in the Actions pane.
As long as you set all the
servers in the web farm to use the same key, they can share view state
and use other features, such as forms authentication. Of course, you
can't create the key string on your own and have it be sufficiently
random. (To the human eye, the validation key and decryption key simply
look like longs strings of meaningless characters.) Instead, on the
first web server, you can ask IIS to generate two sufficiently random
keys by clicking the Generate Keys link in the Actions pane on the
right side.
8. Windows Authentication
The first choice is to use ASP.NET's built-in
forms security system, which uses a login page to authenticate a new
user (usually, by comparing a user name and password against a database
record) and an authentication cookie to keep track of each logged-in
user. The second choice is to use Windows authentication to force each
person to supply the credentials of a valid Windows account that's
defined on the web server (or another server on the network). This
technique is more specialized and less common, but it's sometimes used
inside small companies, especially when creating internal web
applications that have a small set of known users.
It's easy enough to test a
website that uses Windows authentication, because the Visual Studio web
server automatically logs in the current user under the current Windows
account. But on a real web server, you need to configure IIS before it
can perform the same task. That's because IIS supports several
different protocols that it can use when authenticating a user with
Windows authentication. Depending on your network and the level of
security you want, you need to choose the right one. Table 1 describes your options.
Table 1. Windows Authentication Methods
| Method | Description |
|---|
| Anonymous | Anonymous
authentication is technically not a true authentication method, because
the client isn't required to submit any information. Instead, users are
given free access to the website under a special user account, IUSR.
Anonymous authentication is the default. |
| Basic | Basic
authentication is a part of the HTTP standard, and all browsers and web
servers support it. When using Basic authentication, the browser
presents the user with a login box with a user name and password field.
This information is then transmitted to IIS, where it's matched with a
local Windows user account. The disadvantage of Basic authentication is
that the password is transmitted in clear text and is visible over the
Internet (unless you combine it with SSL technology). |
| Digest | Digest
authentication remedies the primary weakness of Basic authentication:
sending passwords in plain text. Digest authentication sends a digest (also known as a hash)
instead of a password over the network. The primary disadvantage is
that Digest authentication needs to use Active Directory or have access
to an Active Directory server. |
| Integrated | Integrated Windows authentication (which is often shortened to just Windows authentication)
is the best choice for most intranet scenarios. When using Integrated
authentication, Internet Explorer can send the required information
automatically using the currently logged-in Windows account on the
client, provided it's on a trusted domain. Most other browser support
Integrated Windows authentication but will prompt the user to supply
login credentials. Integrated authentication won't work across proxy
servers. |
The IIS documentation
has more about these different authentication methods. However,
choosing the one that's right for your network environment may involve
a long discussion with your friendly neighborhood network administrator.
Before you can use any type of
Windows authentication, you need to install the appropriate support for
IIS. (By default, it's an optional feature that isn't included.) To add
support, open the Control Panel, choose Programs and Features, and then
click the link "Turn Windows features on or off." Head to the Internet
Information Services => World Wide Web Services => Security group, which is shown in Figure 14. You'll find settings named Basic Authentication, Digest Authentication, and Windows Authentication.
NOTE
Not all operating
systems include all the options for Windows authentication. If you're
using Windows Server 2008 or the Business or Ultimate edition of
Windows 7 or Windows Vista, you'll have everything you need. But if
you're using another version of Windows 7 or Windows Vista, you won't
have support for two of the most useful authentication methods: Digest
authentication and Integrated Windows authentication.
Once you have the
authentication features you need installed, you simply need to select
your website in IIS manager and double-click the Authentication icon
(in the IIS group). Now you'll see whatever authentication options
you've installed. Figure 15 shows an example on a web server that supports Integrated Windows authentication.
You can enable more than one
authentication method. In this case, the client will use the strongest
authentication method it supports, as long as anonymous access is not
enabled. If anonymous access is enabled, the client will automatically
access the website anonymously, unless the web application explicitly
denies anonymous users with this rule in the web.config file:
<deny users="?" />
